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1. Introduction 


This document introduces a YANG [RFC7950] [RFC6991] data model for 
Layer 3 (L3) network topologies, specifically Layer 3 Unicast. The 
model allows an application to have a holistic view of the topology 
of a Layer 3 network, all contained in a single conceptual YANG 
datastore. The data model builds on top of, and augments, the data 
model for network topologies defined in [RFC8345]. 


This document also shows how the model can be further refined to 
cover different Layer 3 Unicast topology types. For this purpose, an 
example model is introduced that covers OSPF [RFC2328]. This example 
is intended purely for illustrative purpose; we expect that a 
complete OSPF model will be more comprehensive and refined than the 
example shown in this document. 


There are multiple applications for a topology data model. A number 
of use cases have been defined in Section 6 of [USECASE-REQS]. For 
example, nodes within the network can use the data model to capture 
their understanding of the overall network topology and expose it to 
a network controller. A network controller can then use the 
instantiated topology data to compare and reconcile its own view of 
the network topology with that of the network elements that it 
controls. Alternatively, nodes within the network could propagate 
this understanding to compare and reconcile this understanding either 
amongst themselves or with help of a controller. Beyond the network 
element itself, a network controller might even use the data model to 
represent its view of the topology that it controls and expose it to 
applications north of itself. 


The data model for Layer 3 Unicast topologies defined in this 
document is specified in the YANG module "ietf-13-unicast-topology". 
This YANG module augments the general network topology model defined 
in [RFC8345] with information specific to Layer 3 Unicast. In this 
way, the general topology model is extended to be able to meet the 
needs of Layer 3 Unicast topologies. 


Information that is kept in the Traffic Engineering Database (TED) 
will be specified in a separate model [YANG-TE] and is outside the 
Scope of this specification. 


2. Key Words 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 
"OPTIONAL" in this document are to be interpreted as described in 
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all 
capitals, as shown here. 
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Definitions and Acronyms 

This document defines a YANG data model and thus uses many terms 

defined in YANG [RFC7950] and NETCONF [RFC6241]. Some terms, such as 

"datastore" and "data tree", are repeated here for clarity and 

context. 

Datastore: A conceptual place to store and access information. A 
datastore might be implemented, for example, using files, a 
database, flash memory locations, or combinations thereof. A 
datastore maps to an instantiated YANG data tree (definition 
adopted from [RFC8342]). 


Data subtree: An instantiated data node and the data nodes that are 
hierarchically contained within it. 


IS-IS: Intermediate System to Intermediate System protocol 

LSP: Label Switched Path 

NETCONF: Network Configuration Protocol 

NMDA: Network Management Datastore Architecture 

OSPF: Open Shortest Path First (a link-state routing protocol) 
URI: Uniform Resource Identifier 

TED: Traffic Engineering Database 

YANG: YANG is a data modeling language used to model configuration 


data, state data, Remote Procedure Calls, and notifications for 
network management protocols [RFC7950]. 
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4. Model Structure 


The Layer 3 Unicast topology model is defined by YANG module 
"l3-unicast-topology". The relationship of this module with other 
YANG modules is roughly depicted in the figure below. 


R-----------------2------------ t 
| 4+----------------------- + | 
| ietf-network | 
+---------- A—------------ + 
| | 
| 4+----------------------- + | 
| | ietf-network-topology | | 
| +---------- 4------------ + | 
+------------- A--------------- + 
4+------------ A------------- + 
ietf-13-unicast-topology | 
4+—------------ A—------------- + 
| 
| 
+----------- A----------- + 
| example-ospf-topology | 
4+—----------------------- + 


Figure 1: Overall Model Structure 


YANG modules "ietf-network" and "ietf-network-topology" collectively 
define the basic network topology model [RFC8345]. YANG module 
"ietf-13-unicast-topology" augments those models with additional 
definitions needed to represent Layer 3 Unicast topologies. This 
module in turn can be augmented by YANG modules with additional 
definitions for specific types of Layer 3 Unicast topologies, such as 
OSPF and IS-IS topologies. 


The YANG modules "ietf-network" and "ietf-network-topology" are 
designed to be used in conjunction with implementations that support 
the Network Management Datastore Architecture (NMDA) defined in 
[RFC8342]. Accordingly, the same is true for the YANG modules that 
augment it. In order to allow implementations to use the model even 
in cases when NMDA is not supported, companion YANG modules (that 
SHOULD NOT be supported by implementations that support NMDA) are 
defined in Appendix A. 
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5. Layer 3 Unicast Topology Model Overview 


The Layer 3 Unicast topology model is defined by YANG module 
"ietf-13-unicast-topology". Its structure is depicted in the 
following diagram. The notation syntax follows [RFC8340]. For 
purposes of brevity, notifications are not depicted. 


module: ietf-13-unicast-topology 
augment /nw:networks/nw:network/nw:network-types: 
t--rw l3-unicast-topology! 
augment /nw:networks/nw:network: 
t--rw l3-topology-attributes 
t--rw name? string 
t--rw flag* l3-flag-type 
augment /nw:networks/nw:network/nw:node: 
t--rw 13-node-attributes 


t--rw name? inet:domain-name 
t--rw flag* node-flag-type 
t--rw router-id* rt-types:router-id 
t--rw prefix* [prefix] 

t--rw prefix inet:ip-prefix 

t--rw metric? uint32 

t--rw flag* prefix-flag-type 


augment /nw:networks/nw:network/nt:link: 
t--rw l3-link-attributes 


t--rw name? string 
t--rw flag* link-flag-type 
t--rw metricl? uint64 
+--rw metric2? uint64 


augment /nw:networks/nw:network/nw:node/nt:termination-point: 
t--rw l3-termination-point-attributes 
t--rw (termination-point-type)? 


t--: (ip) 
t--rw ip-address* inet:ip-address 
*t--: (unnumbered) 
| *--rw unnumbered-id? uint32 
t--: (interface-name) 
t--rw interface-name? string 


The module augments the original "ietf-network" and "ietf-network- 
topology" modules as follows: 


o A new network topology type is introduced, l3-unicast-topology. 


The corresponding container augments the network-types of the 
"ietf-network" module. 
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o Additional topology attributes are introduced, defined in a 
grouping that augments the "network" list of the network module. 
The attributes include a name for the topology and a set of flags 
(represented by a leaf-list). Each type of flag is represented by 
a separate identity. This allows additional flags to be 
introduced in augmenting modules using additional identities 
without needing to revise this module. 


o Additional data objects for nodes are introduced by augmenting the 
"node" list of the network module. New objects include a set of 
flags and a list of prefixes. Each prefix includes an IP prefix, 
a metric, and a prefix-specific set of flags. 


o Links (in the "ietf-network-topology" module) are augmented with a 
set of parameters that allow a link to be associated with a link 
name, another set of flags, and a link metric. 


o Termination points (in the "ietf-network-topology" module) are 
augmented with a choice of IP address, identifier, or name. 


In addition, the module defines a set of notifications to alert 
clients of any events concerning links, nodes, prefixes, and 
termination points. Each notification includes an indication of the 
type of event, the topology from which it originated, and the 
affected node, link, prefix, or termination point. Also, as a 
convenience to applications, additional data of the affected node, 
link, prefix, or termination point is included. While this makes 
notifications larger in volume than they need to be, it avoids the 
need for subsequent retrieval of context information that might have 
changed in the meantime. 


6. Layer 3 Unicast Topology YANG Module 


This YANG module makes reference to the following documents: 
[RFC2863] and [RFC8343]. 


«CODE BEGINS» file "ietf-13-unicast-topology82018-02-26.yang" 
module ietf-13-unicast-topology { 
yang-version 1.1; 
namespace 
"urn:ietf:params:xml:ns:yang:ietf-l13-unicast-topology"; 
prefix "13t"; 
import ietf-network { 
prefix "nw" 
} 
import ietf-network-topology { 
prefix "nt"; 


} 
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import ietf-inet-types { 
prefix "inet"; 

} 

import ietf-routing-types { 
prefix "rt-types"; 

} 


organization 
"IETF I2RS (Interface to the Routing System) Working Group"; 
contact 
"WG Web: «https://datatracker.ietf.org/wg/i2rs/» 
WG List: <mailto:i2rs@ietf.org> 
Editor: Alexander Clemm 
<mailto:ludwig@clemm.org> 
Editor: Jan Medved 
«mailto: jmedved@cisco.com> 
Editor: Robert Varga 
<mailto:robert.varga@pantheon.tech> 
Editor: Xufeng Liu 
<mailto:xufeng.liu.ietf@gmail.com> 
Editor: Nitin Bahadur 
<mailto:nitin_bahadur@yahoo.com> 
Editor: Hariharan Ananthakrishnan 
<mailto:hari@packetdesign.com>"; 
description 
"This module defines a model for Layer 3 Unicast 
topologies. 


Copyright (c) 2018 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 
to the license terms contained in, the Simplified BSD License 
set forth in Section 4.c of the IETF Trust’s Legal Provisions 
Relating to IETF Documents 
(https://trustee.ietf.org/license-info). 


This version of this YANG module is part of 
RFC 8346; see the RFC itself for full legal notices."; 
revision "2018-02-26" { 
description 
"Initial revision."; 
reference 
"RFC 8346: A YANG Data Model for Layer 3 Topologies"; 
} 


identity flag-identity { 
description "Base type for flags"; 


Clemm, et al. Standards Track [Page 8] 


RFC 8346 YANG Data Model for L3 Topologies March 2018 


} 


typedef 13-event-type { 
type enumeration { 
enum "add" { 
description 
"A Layer 3 node, link, prefix, or termination point has 
been added"; 
} 
enum "remove" { 
description 
"A Layer 3 node, link, prefix, or termination point has 
been removed"; 
} 
enum "update" { 
description 
"A Layer 3 node, link, prefix, or termination point has 
been updated"; 
} 
} 
description "Layer 3 event type for notifications"; 


} 


typedef prefix-flag-type { 
type identityref { 
base "flag-identity"; 
} 
description "Prefix flag attributes"; 


} 


typedef node-flag-type { 
type identityref { 
base "flag-identity"; 
} 
description "Node flag attributes"; 


} 


typedef link-flag-type { 
type identityref { 
base "flag-identity"; 
} 
description "Link flag attributes"; 


} 


typedef 13-flag-type { 
type identityref { 
base "flag-identity"; 
} 
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description "L3 flag attributes"; 
} 


grouping 13-prefix-attributes { 
description 
"L3 prefix attributes"; 
leaf prefix { 
type inet:ip-prefix; 
description 
"IP prefix value"; 
} 
leaf metric { 
type uint32; 
description 
"Prefix metric"; 
} 
leaf-list flag { 
type prefix-flag-type; 
description 
"Prefix flags"; 
} 
} 
grouping l13-unicast-topology-type { 


March 2018 


description "Identifies the topology type to be L3 Unicast."; 


container l13-unicast-topology { 


presence "indicates L3 Unicast topology"; 


description 


"The presence of the container node indicates L3 Unicast 


topology"; 
} 
} 
grouping 13-topology-attributes { 


description "Topology scope attributes"; 


container 13-topology-attributes { 


description "Contains topology attributes"; 


leaf name { 
type string; 
description 
"Name of the topology"; 
} 
leaf-list flag { 
type 13-flag-type; 
description 
"Topology flags"; 


} 


} 
grouping 13-node-attributes { 
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description "L3 node scope attributes"; 
container 13-node-attributes { 
description 
"Contains node attributes"; 
leaf name { 
type inet:domain-name; 
description 
"Node name"; 
} 
leaf-list flag { 
type node-flag-type; 
description 
"Node flags"; 
} 
leaf-list router-id { 
type rt-types:router-igd; 
description 
"Router-id for the node"; 
} 
list prefix { 
key "prefix"; 
description 


March 2018 


"A list of prefixes along with their attributes"; 


uses l3-prefix-attributes; 


} 
} 
} 
grouping 13-link-attributes { 
description 
"L3 link scope attributes"; 
container 13-link-attributes { 
description 
"Contains link attributes"; 
leaf name { 
type string; 
description 
"Link Name"; 
} 
leaf-list flag { 
type link-flag-type; 
description 
"Link flags"; 
} 
leaf metricl { 
type uint64; 
description 
"Link Metric 1"; 
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leaf metric2 ( 

type uint64; 

description 
"Link Metric 2"; 


} 
} 
grouping 13-termination-point-attributes { 
description "L3 termination point scope attributes"; 
container l3-termination-point-attributes { 
description 
"Contains termination point attributes"; 
choice termination-point-type { 
description 
"Indicates the termination point type"; 
case ip { 
leaf-list ip-address ( 
type inet:ip-address; 
description 
"IPv4 or IPv6 address."; 
} 
} 
case unnumbered { 
leaf unnumbered-id { 
type uint32; 
description 
"Unnumbered interface identifier. 
The identifier will correspond to the ifIndex value 
of the interface, i.e., the ifIndex value of the 
ifEntry that represents the interface in 
implementations where the Interfaces Group MIB 
(RFC 2863) is supported."; 
reference 
"RFC 2863: The Interfaces Group MIB"; 


} 
} 
case interface-name { 
leaf interface-name { 
type string; 
description 
"Name of the interface. The name can (but does not 
have to) correspond to an interface reference of a 
containing node’s interface, i.e., the path name of a 
corresponding interface data node on the containing 
node reminiscent of data type interface-ref defined 
in RFC 8343. It should be noted that data type 
interface-ref of RFC 8343 cannot be used directly, 
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as this data type is used to reference an interface 

in a datastore of a single node in the network, not 

to uniquely reference interfaces across a network."; 
reference 

"RFC 8343: A YANG Data Model for Interface Management"; 


} 
} 


augment "/nw:networks/nw:network/nw:network-types" { 
description 
"Introduces new network type for L3 Unicast topology"; 
uses l3-unicast-topology-type; 
} 
augment "/nw:networks/nw:network" { 
when "nw:network-types/13t:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
} 
description 
"L3 Unicast for the network as a whole"; 
uses l3-topology-attributes; 
} 
augment "/nw:networks/nw:network/nw:node" { 
when "../nw:network-types/13t:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
} 
description 
"L3 Unicast node-level attributes "; 
uses 13-node-attributes; 
} 
augment "/nw:networks/nw:network/nt:link" { 
when "../nw:network-types/13t:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
} 
description 
"Augments topology link attributes"; 
uses 13-link-attributes; 
} 
augment "/nw:networks/nw:network/nw:node/" 
+"nt:termination-point" { 
when "../../nw:network-types/13t:13-unicast-topology" { 
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description 
"Augmentation parameters apply only for networks with 


L3 Unicast topology"; 


} 
description "Augments topology termination point configuration"; 


uses l3-termination-point-attributes; 
} 
notification 13-node-event { 
description 
"Notification event for L3 node"; 
leaf l3-event-type { 
type 13-event-type; 
description 
"Event type"; 
} 
uses nw:node-ref; 
uses l3-unicast-topology-type; 
uses 13-node-attributes; 
} 
notification 13-link-event { 
description 
"Notification event for L3 link"; 
leaf l3-event-type { 
type 13-event-type; 
description 
"Event type"; 
} 
uses nt:link-ref; 
uses l3-unicast-topology-type; 
uses 13-link-attributes; 
} 
notification 13-prefix-event { 
description 
"Notification event for L3 prefix"; 
leaf 13-event-type { 
type 13-event-type; 
description 
"Event type"; 
} 
uses nw:node-ref; 
uses l3-unicast-topology-type; 
container prefix { 


description 
"Contains L3 prefix attributes"; 


uses l3-prefix-attributes; 
} 
} 
notification termination-point-event { 
[Page 14] 
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description 

"Notification event for L3 termination point"; 
leaf 13-event-type { 

type 13-event-type; 

description 

"Event type"; 

} 
uses nt:tp-ref; 
uses l3-unicast-topology-type; 
uses l3-termination-point-attributes; 


«CODE ENDS» 
7. Interactions with Other YANG Modules 


As described in Section 4, the model defined in this document builds 
on top of, and augments, the YANG modules defined in [RFC8345]. 
Specifically, the "ietf-13-unicast-topology" module augments the 
"ietf-network" and "ietf-network-topology" modules. In addition, the 
model makes use of data types defined in [RFC6991]. 


The model defined in this document is a protocol-independent YANG 
data model with Layer 3 topology information. It is separate from 
and not linked with data models that are used to configure routing 
protocols or routing information, e.g., "ietf-routing" [RFC8022] and 
"ietf-rib-extension" [YANG-RIB]. That said, the model does import a 
type definition from model "ietf-routing-types" [RFC8294]. 


The model complies with the requirements for the ephemeral state 
found in [RFC8242]. For ephemeral topology data that is server 
provided, the process tasked with maintaining topology information 
will load information from the routing process (such as OSPF) into 
the data model without relying on a configuration datastore. 


8. IANA Considerations 


This document registers the following namespace URIs in the "IETF XML 
Registry" [RFC3688]: 


URI: urn:ietf:params:xml:ns:yang:ietf-13-unicast-topology 
Registrant Contact: The IESG. 
XML: N/A; the requested URI is an XML namespace. 


URI: urn:ietf:params:xml:ns:yang:ietf-l13-unicast-topology-state 


Registrant Contact: The IESG. 
XML: N/A; the requested URI is an XML namespace. 
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This document registers the following YANG modules in the "YANG 
Module Names" registry [RFC6020]: 


Name: ietf-13-unicast-topology 

Namespace: urn:ietf:params:xml:ns:yang:ietf-l13-unicast-topology 
Prefix: 13t 

Reference: RFC 8346 


Name: ietf-13-unicast-topology-state 

Namespace: urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state 
Prefix: l3t-s 

Reference: RFC 8346 


9. Security Considerations 


The YANG modules specified in this document define a schema for data 
that is designed to be accessed via network management protocols such 
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer 
is the secure transport layer, and the mandatory-to-implement secure 
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer 
is HTTPS, and the mandatory-to-implement secure transport is TLS 
[RFC5246]. 


The NETCONF access control model [RFC8341] provides the means to 
restrict access for particular NETCONF or RESTCONF users to a 
preconfigured subset of all available NETCONF or RESTCONF protocol 
operations and content. 


In general, Layer 3 Unicast topologies are system-controlled and 


provide ephemeral topology information. In an NMDA-compliant server, 
they are only part of «operational», which provides read-only access 
to clients, so they are less vulnerable. That said, the YANG modules 


do in principle allow information to be configurable. 


There are a number of data nodes defined in these YANG modules that 
are writable/creatable/deletable (i.e., config true, which is the 
default). These data nodes may be considered sensitive or vulnerable 
in some network environments. Write operations (e.g., edit-config) 
to these data nodes without proper protection can have a negative 
effect on network operations. These are the subtrees and data nodes 
and their sensitivity/vulnerability in the "ietf-13-unicast-topology" 
module: 


o 13-topology-attributes: A malicious client could attempt to 


sabotage the configuration of any of the contained attributes, 
i.e., the name or the flag data nodes. 
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o 13-node-attributes: A malicious client could attempt to sabotage 
the configuration of important node attributes, such as the 
router-id or node prefix. 


o 13-link-attributes: A malicious client could attempt to sabotage 
the configuration of important link attributes, such as name, 
flag, and metrics of the link. 


o 13-termination-point-attributes: A malicious client could attempt 
to sabotage the configuration information of a termination point, 
such as the termination point's IP address and interface name. 
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Appendix A. Companion YANG Data Model for Implementations Not Compliant 
with NMDA 


The YANG module "ietf-13-unicast-topology" defined in this document 


augments two modules defined in [RFC8345]: "ietf-network" and 
"ietf-network-topology". These two modules were designed to be used 
in conjunction with implementations that support the Network 
Management Datastore Architecture (NMDA) defined in [RFC8342]. In 


order to allow implementations to use the model in cases when NMDA is 
not supported, [RFC8345] defines two companion modules, 
"ietf-network- state" and "ietf-network-topology-state", that 
represent state models of networks and network topologies, 
respectively. 


In order to be able to use the model for Layer 3 topologies defined 
in this document in conjunction with implementations not compliant 
with NMDA, a corresponding companion module needs to be introduced as 
well. This companion module, "ietf-13-unicast-topology-state", 
mirrors "ietf-13-unicast-topology". However, the module augments 
"ietf-network-state" and "ietf-network-topology-state" (instead of 
"ietf-network" and "ietf-network-topology"), and all of its data 
nodes are non-configurable. 


Similar considerations apply to any module that augments "ietf-13- 
unicast-topology", such as the example module defined in Appendix B 
(i.e., example-ospf-topology). For implementations that are not 
compliant with NMDA, companion modules that represent state 
information and that are non-configurable will need to be introduced. 
These modules augment "ietf-13-unicast-topology-state" instead of 
"ietf-13-unicast-topology". Companion modules for the example module 
defined in Appendix B are not provided (since it is just an example). 


Like "ietf-network-state" and "ietf-network-topology-state", 
"ietf-l13-unicast-topology" SHOULD NOT be supported by implementations 
that support NMDA. The module is therefore defined in an appendix. 


The definition of the module follows below. As the structure of the 
module mirrors that of its underlying module, the YANG tree is not 
depicted separately. 


«CODE BEGINS» file "ietf-l13-unicast-topology-state82018-02-26.yang" 
module ietf-13-unicast-topology-state { 
yang-version 1.1; 
namespace 
"urn:ietf:params:xml:ns:yang:ietf-l3-unicast-topology-state"; 
prefix "13t-s"; 
import ietf-network-state { 
prefix "nw-s"; 
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} 
import ietf-network-topology-state { 
prefix "nt-s"; 
} 
import ietf-13-unicast-topology { 
prefix "13t"; 
} 
organization 
"IETF I2RS (Interface to the Routing System) Working Group"; 
contact 


"WG Web: «https://datatracker.ietf.org/wg/i2rs/» 
WG List: <mailto:i2rs@ietf.org> 
Editor: Alexander Clemm 
<mailto:ludwig@clemm.org> 
Editor: Jan Medved 
<mailto: jmedved@cisco.com> 
Editor: Robert Varga 
<mailto:robert.varga@pantheon.tech> 
Editor: Xufeng Liu 
<mailto:xufeng.liu.ietf@gmail.com> 
Editor: Nitin Bahadur 
<mailto:nitin_bahadur@yahoo.com> 
Editor: Hariharan Ananthakrishnan 


<mailto:hari@packetdesign.com>"; 
description 
"This module defines a model for Layer 3 Unicast topology 
state, representing topology that either is learned or 
results from applying topology that has been configured per 
the ’ietf-13-unicast-topology’ model, mirroring the 
corresponding data nodes in this model. 


This model mirrors 'ietf-l3-unicast-topology' but contains only 


read-only state data. The model is not needed when the 


underlying implementation infrastructure supports the Network 


Management Datastore Architecture (NMDA). 


Copyright (c) 2018 IETF Trust and the persons identified as 
authors of the code. All rights reserved. 


Redistribution and use in source and binary forms, with or 
without modification, is permitted pursuant to, and subject 


to the license terms contained in, the Simplified BSD License 
set forth in Section 4.c of the IETF Trust's Legal Provisions 


Relating to IETF Documents 
(https://trustee.ietf.org/license-info). 


This version of this YANG module is part of RFC 8346; 
see the RFC itself for full legal notices."; 
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revision "2018-02-26" { 
description 
"Initial revision."; 
reference 
"RFC 8346: A YANG Data Model for Layer 3 Topologies"; 
} 
augment "/nw-s:networks/nw-s:network/nw-s:network-types" { 
description 
"Introduce new network type for L3 Unicast topology"; 
uses l3t:13-unicast-topology-type; 
} 
augment "/nw-s:networks/nw-s:network" { 
when "nw-s:network-types/13t-s:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
} 
description 
"L3 Unicast for the network as a whole"; 
uses 13t:13-topology-attributes; 
} 
augment "/nw-s:networks/nw-s:network/nw-s:node" { 
when "../nw-s:network-types/13t-s:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
} 
description 
"L3 Unicast node-level attributes "; 
uses 13t:13-node-attributes; 
} 
augment "/nw-s:networks/nw-s:network/nt-s:link" { 
when "../nw-s:network-types/13t-s:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
} 
description 
"Augments topology link attributes"; 
uses 13t:13-link-attributes; 
} 
augment "/nw-s:networks/nw-s:network/nw-s:node/" 
+"nt-s:termination-point" { 
when "../../nw-s:network-types/13t-s:13-unicast-topology" { 
description 
"Augmentation parameters apply only for networks with 
L3 Unicast topology"; 
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description "Augments topology termination point configuration"; 


uses l3t:l3-termination-point-attributes; 
} 
notification 13-node-event { 
description 
"Notification event for L3 node"; 
leaf l3-event-type { 
type 13t:13-event-type; 
description 
"Event type"; 
} 
uses nw-s:node-ref; 
uses l3t:13-unicast-topology-type; 
uses 13t:13-node-attributes; 
} 
notification 13-link-event { 
description 
"Notification event for L3 link"; 
leaf l3-event-type { 
type 13t:13-event-type; 
description 
"Event type"; 
} 
uses nt-s:link-ref; 
uses l3t:13-unicast-topology-type; 
uses 13t:13-link-attributes; 
} 
notification 13-prefix-event { 
description 
"Notification event for L3 prefix"; 
leaf 13-event-type { 
type 13t:13-event-type; 
description 
"Event type"; 
} 
uses nw-s:node-ref; 
uses l3t:13-unicast-topology-type; 
container prefix { 
description 
"Contains L3 prefix attributes"; 
uses 13t:13-prefix-attributes; 
} 
} 


notification termination-point-event { 
description 
"Notification event for L3 termination point"; 
leaf 13-event-type { 
type 13t:13-event-type; 
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description 
"Event type"; 
} 
uses nt-s:tp-ref; 
uses l3t:13-unicast-topology-type; 
uses l3t:l3-termination-point-attributes; 


} 


<CODE ENDS> 
Appendix B. Extending the Model 


The model can be extended for specific Layer 3 Unicast types. 
Examples include OSPF and IS-IS topologies. This appendix introduces 
a YANG module that defines a simple topology model for OSPF. This 
module is intended to serve as an example that illustrates how the 
general topology model can be refined across multiple levels. It 
does not constitute a full-fledged OSPF topology model, which may be 
more comprehensive and refined than the model that is described here. 


B.1. Example OSPF Topology 
B.1.1. Model Overview 


The following model shows how the Layer 3 Unicast topology model can 
be extended, in this case, to cover OSPF topologies. For this 
purpose, a set of augmentations are introduced in a separate YANG 
module, "example-ospf-topology", whose structure is depicted in the 
following diagram. As before, the notation syntax follows [RFC8340]. 
Note that one of the lines has been wrapped to adhere to the 
72-character line limitation of RFCs. 
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module: example-ospf-topology 
augment /nw:networks/nw:network/nw:network-types/ 
13t:13-unicast-topology: 
t--rw ospf! 
augment /nw:networks/nw:network/13t:13-topology-attributes: 
t--rw ospf-topology-attributes 
t--rw area-id? area-id-type 
augment /nw:networks/nw:network/nw:node/13t:13-node-attributes: 
t--rw ospf-node-attributes 
t--rw (router-type)? 


| +--: (abr) 
| | +--rw abr? empty 
| *--: (asbr) 
| +--rw asbr? empty 
| t--: (internal) 
| +--rw internal? empty 
+--: (pseudonode) 
| +--rw pseudonode? empty 
t--rw dr-interface-id? uint32 


augment /nw:networks/nw:network/nt:link/13t:13-link-attributes: 
t--rw ospf-link-attributes 
augment /13t:13-node-event: 


t---- ospf! 
t---- ospf-node-attributes 
t---- (router-type)? 
| +--: (abr) 
| +---- abr? empty 
+--: (asbr) 
t---- asbr? empty 
| *--: (internal) 
| | +---- internal? empty 
| +--: (pseudonode) 
| +---- pseudonode? empty 
t---- dr-interface-id? uint32 
augment /13t:13-link-event: 
t---- ospf! 
t---- ospf-link-attributes 


The module augments "ietf-l13-unicast-topology" as follows: 

o A new topology type for an OSPF topology is introduced. 

o Additional topology attributes are defined in a new grouping that 
augments l3-topology-attributes of the "ietf-l13-unicast-topology" 


module. The attributes include an OSPF area-id identifying the 
OSPF area. 
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o Additional data objects for nodes are introduced by augmenting the 
l3-node-attributes of the "ietf-13-unicast-topology" module. New 
objects include router-type and dr-interface-id for pseudonodes. 


o Links are augmented with OSPF link attributes. 


In addition, the module extends notifications for events concerning 
Layer 3 nodes and links with OSPF attributes. 


It should be noted that the model defined here represents topology 
and is intended as an example. It does not define how to configure 
OSPF routers or interfaces. 


B.1.2. OSPF Topology YANG Module 


The OSPF Topology YANG module is specified below. As mentioned, the 
module is intended as an example for how the Layer 3 Unicast topology 
model can be extended to cover OSPF topologies, but it is not 
normative. Accordingly, the module is not delimited with 

«CODE BEGINS» and «CODE ENDS» tags. 


file "example-ospf-topology82017-12-16.yang" 
module example-ospf-topology { 
yang-version 1.1; 
namespace "urn:example:example-ospf-topology"; 
prefix "ex-ospft"; 
import ietf-yang-types { 
prefix "yang"; 
} 
import ietf-network { 
prefix "nw" 
} 
import ietf-network-topology { 
prefix "nt"; 
} 
import ietf-13-unicast-topology { 
prefix "13t"; 
} 
description 
"This module is intended as an example for how the 
Layer 3 Unicast topology model can be extended to cover 
OSPF topologies."; 
typedef area-id-type { 
type yang:dotted-quad; 
description 
"Area ID type."; 
} 
grouping ospf-topology-type { 
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description 

"Identifies the OSPF topology type."; 
container ospf { 

presence "indicates OSPF Topology"; 

description 

"Its presence identifies the OSPF topology type."; 
} 
} 


augment "/nw:networks/nw:network/nw:network-types/" 
+ "13t:13-unicast-topology" { 
description 
"Defines the OSPF topology type."; 
uses ospf-topology-type; 


} 
augment "/nw:networks/nw:network/13t:13-topology-attributes" { 


when "../nw:network-types/13t:13-unicast-topology/" + 
"ex-ospft:ospf" { 
description 


"Augments only for OSPF topology"; 
} 
description 
"Augments topology configuration"; 
container ospf-topology-attributes { 
description 
"Contains topology attributes"; 
leaf area-id { 
type area-id-type; 
description 
"OSPF area ID"; 


} 


augment "/nw:networks/nw:network/nw:node/13t:13-node-attributes" { 
"../../nw:network-types/13t:13-unicast-topology/" + 
"ex-ospft:ospf" { 
description 
"Augments only for OSPF topology"; 


when 


} 
description 

"Augments node configuration"; 
uses ospf-node-attributes; 


} 
augment "/nw:networks/nw:network/nt:link/13t:13-link-attributes" { 


when "../../nw:network-types/13t:13-unicast-topology/" + 
"ex-ospft:ospf" { 
description 


"Augments only for OSPF topology"; 
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description 
"Augments link configuration"; 
uses ospf-link-attributes; 
} 
grouping ospf-node-attributes { 
description 
"OSPF node scope attributes"; 
container ospf-node-attributes { 
description 
"Contains node attributes"; 
choice router-type { 
description 
"Indicates router type"; 
case abr { 
leaf abr { 
type empty; 
description 
"The node is ABR"; 
} 
} 
case asbr { 
leaf asbr { 
type empty; 
description 
"The node is ASBR"; 
} 
} 
case internal { 
leaf internal { 
type empty; 
description 
"The node is internal"; 
} 
} 
case pseudonode { 
leaf pseudonode { 
type empty; 
description 
"The node is pseudonode"; 


} 
} 
leaf dr-interface-id { 
when "../pseudonode" { 
description 
"Valid only for pseudonode"; 
} 
type uint32; 
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} 


default "0"; 
description 
"For pseudonodes, DR interface-id"; 


} 
} 
grouping ospf-link-attributes { 
description 
"OSPF link scope attributes"; 
container ospf-link-attributes { 
description 
"Contains OSPF link attributes"; 
} 
} // ospf-link-attributes 
augment "/13t:13-node-event" { 
description 
"OSPF node event"; 
uses ospf-topology-type; 
uses ospf-node-attributes; 
} 
augment "/13t:13-link-event" { 
description 
"OSPF link event"; 
uses ospf-topology-type; 
uses ospf-link-attributes; 


Appendix C. An Example 


This section contains an example of an instance data tree in JSON 


encoding [RFC7951]. The example instantiates "ietf-13-unicast- 
topology" for the topology that is depicted in the following diagram. 
There are three nodes: D1, D2, and D3. D1 has three termination 


points: 1-0-1, 1-2-1, and 1-3-1. D2 has three termination points as 
well: 2-1-1, 2-0-1, and 2-3-1. D3 has two termination points: 3-1-1 
and 3-2-1. In addition, there are six links, two between each pair 
of nodes, with one going in each direction. 
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Figure 2: A Network Topology Example 


The corresponding instance data tree is depicted below. Note that 
some lines have been wrapped to adhere to the 72-character line 
limitation of RFCs. 


"ietf-network:networks": { 
"network": [ 
{ 
"network-types": { 
"ietf-13-unicast-topology:13-unicast-topology": {} 
DÉI 


"network-id": "l3-topo-example", 
"node": [ 
( 
"node-rg"e "pj", 
"Ltermination-point": [ 
: Vë e kee E: dé De AER 
"ietf-13-unicast-topology: 
l3-termination-point-attributes": { 
"unnumbered-id:": 101 
} 
DÉI 
{ 
"Epid": "]1—-2-—15; 
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"ietf-13-unicast-topology: 


l3-termination-point-attributes": 


"unnumbered-id:": 121 
} 
DÉI 
{ 


"Ütp-cid"s Wé Re 
"ietf-l13-unicast-topology: 


l3-termination-point-attributes": 


"unnumbered-id:": 131 


} 
l; 


"ietf-l13-unicast-topology:13-node-attributes": 


"router-id": ["203.0.113.1"] 
) 
), 
{ 


"node-id": "D2", 
"Ltermination-point": [ 
{ 
Tepig"; We E 
"ietf-13-unicast-topology: 


l3-termination-point-attributes": 


"unnumbered-id:": 201 
} 
hy 
{ 


"tp-id"s "Decl", 
"ietf-13-unicast-topology: 


l3-termination-point-attributes": 


"unnumbered-id:": 211 
} 
DÉI 
{ 


"tp-ord"s "2=3=1L"; 
"ietf-13-unicast-topology: 


l3-termination-point-attributes": 


"unnumbered-id:": 231 


} 
l; 


"ietf-13-unicast-topology:13-node-attributes": 


"router-id": ["203.0.113.2"] 
} 
), 
{ 


"node-id": "D3", 
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"termination-point": [ 
{ 
"tp-arid"'s WE KE BA 
"ietf-13-unicast-topology: 
l3-termination-point-attributes": { 
"unnumbered-id:": 311 
} 
DÉI 
{ 
"tp-caid"s "pp". 
"ietf-13-unicast-topology: 
l3-termination-point-attributes": { 
"unnumbered-id:": 321 


} 
l; 
"ietf-13-unicast-topology:13-node-attributes": { 
"router-id"z. [*203.0.1T3.3"] 
} 
} 
l; 
"ietf-network-topology:link": [ 
{ 
"Iiink=idr; "Dl;1-2-1;,D2,2-1-I1*"; 
"source": { 
"source-node": "D1", 
"source-tp": "1-2-1" 
} 
"destination": { 
"dest-node": "D2", 
"dest-tp": "2-1-1" 
DÉI 
"ietf-13-unicast-topology:l3-link-attributes": { 


"metricl": "100" 
} 
DÉI 
1 
"dluinkerd"s "Dp2,;2-1-17;Dl,;1-22-1"; 
"source": { 
"source-node": "D2", 
"source-tp": "2-1-1" 
} 
"destination": { 
"dest-node": "D1", 
"dest-tp": "1-2-1" 


DÉI 
"ietf-13-unicast-topology:l3-link-attributes": { 
"metricl": "100" 
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"bink-id':s "DI,1—3-T,D3,;3-1-T", 
"source": { 
"source-node": "D1", 
"SOource-tp"':; "43-1" 
} 
"destination": { 
"dest-node": "D3", 
"dest-tp": "3-1-1" 
DÉI 
"ietf-13-unicast-topology:l3-link-attributes": { 
"ietrricl"s: "3007" 


} 


"link-id":;. "D3,3-1-1,DIl,1-3-1", 
"source": { 
"source-node": "D3", 
"source-tp": "3-1-1" 
} 
"destination": { 
"dest-node": "D1", 
"dest-tp"i "1-3-1" 
DÉI 
"ietf-13-unicast-topology:l3-link-attributes": { 
"metricl": "100" 


} 


"bink-rid"s 752;2-3-1,D3,3-2-1", 
"source": { 
"source-node": "D2", 
"source-tp": "2-3-1" 
} 
"destination": { 
"dest-node": "D3", 
"dest-tp'"; "3=2-1" 
DÉI 
"ietf-13-unicast-topology:l3-link-attributes": { 
metrici» 71007 


} 


"link-id": "D3,3-2-1,D2,2-3-1", 
"source": { 
"source-node": "D3", 
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"source-tp": "3-2-1" 
} 
"destination": { 
"dest-node": "D2", 
"dest-tp": "2-3-1" 
), 
"ietf-13-unicast-topology:l3-link-attributes": { 
"metricl": "100" 
} 
} 
] 
} 
] 
} 
} 
Figure 3: Instance Data Tree 
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